A network element can include two different planes that are used to process network traffic, a control plane and a data plane. The data plane receives, processes, and forwards network traffic using various configuration data (e.g., forwarding, security, quality of service (QoS), and other network traffic processing information). For example, for each received packet of the network traffic, the data plane determines a destination address of that packet, looks up the requisite information for that destination in one or more tables stored in the data plane, and forwards the packet out the proper outgoing interface. The control plane gathers the configuration data from different sources (e.g., locally stored configuration data, via a command line interface, or other management channel such as Simple Network Management Protocol (SNMP)) and configures the data plane using the configuration data.
In addition, the control plane will store the configuration data in one or more tables. For example, the network element will store the routing information in a routing table that is used by the data plane. The data plane can further include multiple different hardware forwarding engines. Each of these hardware forwarding engines will use the configuration data from these tables by reading the tables in the control plane and updating local copies of the tables for each of the hardware forwarding engines. The control plane includes a writer that writes the configuration data, where multiple readers for the hardware forwarding engines read this data. A problem that can arise is that one of the multiple readers attempts to read data from one of the tables that the writer is currently updating. For example, if a reader reads data that is concurrently being modified by the writer, the reader may read data that is partially updated and, thus, is not valid data that is usable by the reader.
In addition, the readers are useful for building asynchronous, distributed, cooperating processes. Process logic is triggered upon receipt of attribute notifications delivered via the reader from tables, producing further state changes for other services that correspond to this process. The attribute notifications can include updated configuration data for a process that describes an aspect of a state of the originating process. The tables are a central clearinghouse of state, responsible for storage and delivery to the readers and corresponding processes and services. This notification model is a useful mechanism for distributed software development. For example, one way to use notifications is to build a queue in which every change is recorded as a “key” within the table and its new associated value. However, the performance of this type of implementation supports only limited sized tables. For example, the notification model can adequately support routing tables with up to 16,000 routes and updating 8-10 readers. This model, however, may not be able to support tables up to one million routes and 32 readers. Furthermore, this model is implemented with static sized tables that may be inadequately sized for the current operating state of the network element.
Furthermore, the writer can populate one or more counters that are used to keep track of the health and performance of the network element. The counter is a piece of memory that is used to store data that is updated often. For example, a counter can be used to track various data regarding the operation of the network element, such as packets transmitted/received, bytes transmitted/received, dropped packets, number of collisions, and other types of data. An administrator can use a tool, such as a command line interface (CLI) or a network management system (NMS) to retrieve the counter data. However, current tools are slow or have high overhead that limits the number of counters that can be allocated and used on a network element.